… filter bitset

cuvs_cagra::get_preference() returned MemoryType::kHostMmap, which the
benchmark framework used to provide the filter bitset as a file-backed
mmap pointer. GPU kernels cannot read host mmap memory on non-ATS GPUs
(A100, H100, V100), causing the filter to be silently non-functional and
recall to collapse to approximately the filter pass rate regardless of
itopk. On ATS-capable GPUs (GH200), the file-backed mmap pages are not
pre-faulted, triggering a cascade of concurrent ATS page faults during
graph traversal and producing incorrect results.

Fix 1: Change get_preference() to return MemoryType::kDevice so the
framework explicitly copies the filter bitset and dataset to device
memory before CAGRA's kernels access them. This is correct on all GPUs.

Fix 2: With kDevice, the framework copies the full dataset to device
before calling set_search_dataset(). The original set_search_param()
then called copy_with_padding() unconditionally, doubling device memory
usage (e.g. 2x 38.4 GB for deep-100M) and causing OOM. Skip
copy_with_padding() when the dataset is already on device and no
16-byte alignment padding is required.

Fix 3: sub_indices_ accumulates corrupted state when the kDevice path
triggers the dataset update code path. For single-index CAGRA,
sub_indices_ is always logically empty, so reset it via placement new
in copy() to prevent bad_array_new_length when the copy constructor runs.

Tested on H100 80GB (no ATS) and GH200 (ATS) with deep-1M/deep-100M,
5% filter pass rate, inner product distance. Recall with kHostMmap
(unpatched): 0.0495 across all itopk values. Recall with kDevice (fix):
0.45-0.9999 scaling correctly with itopk, reaching >0.99 at itopk=1024.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…emory_type

The original fix (kHostMmap -> kDevice for dataset_memory_type) corrected
the bug but removed support for datasets larger than GPU memory. This revision
restores kHostMmap for the dataset and introduces a separate filter_memory_type
property so the filter bitset can be placed on device independently.

Root cause: cuvs_cagra::get_preference() returned kHostMmap for both the
dataset and the filter bitset. CAGRA's search dispatch calls
bitset_view::count() on the filter, which wraps the bitset pointer in
make_device_vector_view and passes it to raft::popc. With a kHostMmap
pointer, this reads un-faulted file-backed mmap pages from the GPU:
- On ATS GPUs (GH200): GPU hardware reaches host memory, but un-faulted
  pages return zeros/garbage -> wrong filtering_rate -> incorrect recall
- On non-ATS GPUs (H100, A100): GPU cannot access host mmap at all ->
  garbage filter bits -> recall collapses to ~pass_rate (random results)

Fix: add filter_memory_type to algo_property (optional, defaults to
dataset_memory_type for backward compatibility). cuvs_cagra sets
filter_memory_type = kDevice so the benchmark framework explicitly copies
only the filter bitset to device memory, while the dataset remains in
kHostMmap to support large-dataset workloads.

Changes:
- ann_types.hpp: add std::optional<MemoryType> filter_memory_type to
  algo_property, defaulting to nullopt (backward compatible)
- benchmark.hpp: parse filter_memory_type from JSON config; use
  filter_memory_type.value_or(dataset_memory_type) when loading filter bitset
- cuvs_cagra_wrapper.h: set filter_memory_type = kDevice in get_preference()

Tested on H100 80GB (deep-1M, 5% filter, k=10). Unpatched: recall ~0.05
(random). Patched: recall 0.45-0.9999 scaling correctly with itopk.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>